For initiating a communication session through a network, several cooperating individual (sub-)sessions, each through a domain (e.g. sub-network), may be needed. In a network depicted in FIG. 1, obviously, the end-to-end route of a session is not clear beforehand, nor is it clear at the originating domain if the session can be made with a required or desired Quality of Service (QoS). A session to be initiated may pass e.g. an origination local domain, an originating national domain, an international domain, a terminating national domain and a terminating local domain.
QoS signalling is known as such from e.g. references 1 and 2, disclosing several ways of performing QoS signalling. Yet QoS signalling implementations in global networks do not exist yet. The prior art methods have several shortcomings which will be outlined here by means of an example.
If a domain in e.g. the Netherlands (NL), shown in FIG. 1, receives a session request which originates in Amsterdam (ASD) and has Tokyo (TYO) as destination location, the controlling means of the NL domain has e.g. a choice between two international domains, e.g. AT&T and Sprint. On receiving the session request, the question for the NL domain is twofold, viz.                1. What next domain must be gone to (i.e. AT&T or Sprint in this example)?        2. Can the requested end-to-end QoS be obtained?        
An answer to these questions may be based on the status of the NL domain, the Service Level Agreements (SLAs) between NL and AT&T, NL and Sprint, and the SLAs of both international domains with their respective Japanese domain(s).
Before continuing, a clear understanding may be needed of what is in an SLA and where an SLA resides in technical sense. Consider the structure of domains as given in FIG. 1. Three international domains A, B and C may be connected to domain JP. Traffic from each domain A, B and C arrives at domain JP at its own physical interface. Usually at this interface shaping, policing, SLA verification, access traffic handling, measurements (e.g. for billing) etc. are performed. These are important actions defined in an SLA. Then the traffic from the domains A, B and C is combined at a multiplexer and enters domain JP. Classification of traffic inbound domain JP, which is another important aspect of an SLA, may take place at the physical interfaces or at a multiplexer. Domain JP can now handle traffic according to its own classes as defined in its SLAs. At a higher level an SLA exists technically at an interface between two neighbouring domains.
To show what can be expected to be in an SLA, an example is considered of the contents of an SLA file.                A chapter describing the physical interface        A chapter describing the traffic classes                    which classes does the domains support?            how are the classes implemented technically (syntax)?            what is the meaning of each class (semantics)?                        A chapter describing traffic handling per class                    measurement definition and timing            amount of bandwidth reserved for a class            QoS guarantees for traffic within a class bandwidth limit            arrangements for handing access traffic                        A financial chapter                    the cost for handling traffic per class            the cost for handling access traffic per class                        
Note that in theory, this can be defined differently for different ingress/egress combinations for the same domain. For instance, QoS guarantees from a NL Point of Presence (POP) of an international domain to Japan might be different than to Spain because of the different distance.
When a request for a session from ASD to TYO is received, an end-to-end “SLA calculator” might be used to compute the SLA from the various SLAs, e.g.                SLA1=SLA(NL, A, B)+SLA(Sprint, B, JP)        SLA2=SLA(NL, A, D)+SLA(AT&T, D, JP), etc.where SLA(X,Y,Z) is a notation for SLA information provided by domain X for traffic entering it from domain Y and leaving it to domain Z.        
However, this may violate the “requirement” that no new protocol should be needed for end-to-end QoS signalling of a session. Besides, a substantial drawback is that the SLA calculator would have to be invoked for each session by each domain, which results in a large overhead at each session setup. Finally, commercial SLA information should be kept confidential. However, if SLA information is exchanged between various domains, each individual SLA may be reverse-engineered, which may be unacceptable for the domain providers which, after all, are in mutual commercial competition.